声明
本文是学习GB-T 33740-2017 手机支付 基于2.45GHz RCC 限域通信 技术的非接触射频接口测试方法. 而整理的学习笔记,分享出来希望更多人受益,如果存在侵权请及时联系我们
1 范围
本标准规定了基于2.45 GHz
RCC(限域通信)技术的非接触射频接口的测试方法,包括物理层、数
据链路与传输会话协议层的测试环境、测试方法和步骤等内容。
本标准适用于基于2.45 GHz
RCC(限域通信)技术的非接触射频接口协议符合性测试。
2 规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅注日期的版本适用于本文
件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。
GB/T 33736—2017 手机支付 基于2.45 GHz
RCC(限域通信)技术的非接触射频接口技术要求
3 术语和定义
下列术语和定义适用于本文件。
3.1
限域通信 range controlled communication
通讯距离范围可控的无线近距离通信技术。
3.2
发 起 方 initiator
2.45 GHz手机支付系统距离控制通信的发起命令请求的一方。
3.3
响应方 target
2.45 GHz手机支付系统对命令请求做出响应的通信方。
3.4
接入标识码 access identifier
用于标识不同的接入响应会话。
3.5
多响应方冲突 multi target collision
多个响应方位于同一个发起方的可接入范围内,发起方将随机地选择任意一个响应方进行接入,使
得用户无法直观判断出被接入的响应方,从而造成本次交易具有不确定性。
3.6
冲突检测码 collision detect code
用于冲突检测的识别码。
GB/T 33740—2017
3.7
响应方随机标识 target random indentifier
用于冲突检测关闭时,响应方进行连接确认的随机识别码。
3.8
冲突响应时间窗 collsion response time window
响应方在检测到 MTC 冲突后连续发送冲突响应消息的时间段。
3.9
会话命令超时时间 session command timeout
响应方接收超时:发起方应当在规定的超时时间内发出相应的会话命令,否则响应方认为该次会话
发起方超时。
发起方接收超时:响应方应当在规定的超时时间内对发起方的命令做出响应,否则发起方认为该次
会话响应方超时。
3.10
磁通道基本消息 magnetic channel message
在磁通道上传输的长度不大于15字节的消息。
3.11
磁通道扩展消息 extended magnetic channel message
在磁通道上传输的长度大于15字节的消息。
3.12
被测设备 DUT
被测试对象,为响应方或者发起方。
3.13
发起方测试仪 iTester
用于模拟响应方,对发起方DUT 进行空中接口协议测试。
3.14
响应方测试仪 tTester
用于模拟发起方,对响应方DUT 进行空中接口协议测试。
3.15
测试流程 test scenario
与测试步骤相对应的由一组测试命令及其响应组成的特定序列。
3.16
测试指令 test command
测试专用的特殊消息命令。
3.17
工作区域 operating range
发起方DUT
或者响应方测试仪的工作区域,为响应方在其表面正上方的可接入范围。
3.18
静默 Mute
DUT 在接收到测试指令后不做任何响应。
4 符号和缩略语
4.1 符号
下列符号适用于本文件。
GB/T 33740—2017
bx: 数据的第 x 个 bit位,x 为十进制数。
A(X)xx: 'A '代表具体的测试命令的名称。
‘X
'可以为无效的测试命令'e',或者为有效的测试命令't'、'tl'、't2'、't3'、't4'。
‘xx'是命令的下标编号,为两位十进制数。
4.2 缩略语
下列缩略语适用于本文件。
AID: 接入标识码 (Access ID)
DUT: |
被测设备
|
(Device Under Test)
|
GFSK; |
高斯频移键控
|
(Gaussian Frequency-Shift Keying)
|
LMF: |
长消息编码格式
|
(Long Message Format)
|
MC: |
磁通道
|
(Magnetic Channel)
|
PRBS: |
伪随机二进制序列
|
(Pseudorandom Binary Sequence)
|
RC: |
射频通道
|
(RF Channel)
|
RCC: 限域通信 (Range Controlled Communication)
RFU; |
保留
|
(Reserve for Future Use)
|
tTester; |
响应方测试仪
|
(Target Tester)
|
5 物理层测试
5.1 测试对象
本标准针对发起方和响应方分别进行物理层测试,包括对发起方磁通道和射频通道的物理层测试、
以及对响应方磁通道和射频通道的物理层测试。
5.2 测试环境
按照图1所述方式,对发起方磁通道测试环境进行连接配置,按照图2所述方式,对响应方磁通道
测试环境进行连接配置,按照图3所述方式,对射频通道测试环境进行连接配置。
除非另有说明,测试应在环境温度为24℃土3℃(73 F±5F)、
相对湿度为40%~60%之间的环
境下进行。
5.3 默认容许误差
除非另有说明,测量设备和测试过程的默认容许误差为土5%。
GB/T 33740—2017
5.4 物理层测试配置
5.4.1 发起方磁通道测试配置
发起方磁通道测试装置包括:被测发起方、标准感应线圈、双绞线或同轴电缆、数字示波器及探头,
测试配置如图1所示。
style="width:7.69328in;height:2.10012in" />双绞线/
同轴电缆
style="width:0.15324in;height:0.12246in" />
数字
示波器
图 1 发起方磁通道测试配置示意图
配置应满足以下要求:
a) 标准感应线圈符合附录 A 的规定;
b) 被测发起方与标准感应线圈相互平行且同轴,其相互之间的垂直距离r,
在测量不同指标时分 别设置如下:
—测量被测发起方数据编码符号率和符号周期抖动时,r,=0 cm;
--测量被测发起方表面磁信号强度时,r=0 cm;
——测量被测发起方10 cm 磁信号强度时,r,=10 cm。
c)
双绞线或者同轴电缆的一端连接标准感应线圈的输出端口,另一端连接数字示波器探头;
d) 数字示波器及其探头的带宽应不小于20 kHz, 测量精度应不小于10
uV/Div。 磁通道感应电压与场强的推导参见附录B。
5.4.2 响应方磁通道测试配置
响应方磁通道测试装置包括:被测响应方、响应方驱动设备以及标准发起方,测试配置如图2所示。
style="width:6.07999in;height:2.5399in" />
图 2 响应方磁通道测试配置示意图
配置应满足以下要求:
a) 标准发起方符合GB/T 33736—2017;
b)
响应方驱动设备应能驱动被测响应方正常工作,且对磁通道信号不产生屏蔽作用;
c)
被测响应方装载于响应方驱动设备中,被测响应方与标准发起方相互平行且同轴。
GB/T 33740—2017
5.4.3
发起方/响应方射频通道测试配置
发起方/响应方射频通道测试配置如图3所示,DUT
为被测发起方或者被测响应方。
style="width:5.28681in;height:2.08681in" />
图 3 发起方/响应方射频通道测试配置示意图
发起方/响应方射频通道测试装置主要指频谱分析仪。频谱分析仪应具备下列功能特性:
——通用频率域的测量;
——频率范围:10 MHz~3GHz;
——检波方式:可选峰值或平均值;
—RF 输入阻抗:标称50 Ω;
——具有 FSK 解调功能。
5.5 发起方磁通道测试项目
5.5.1 数据编码符号率测试
测试项目:数据编码符号率
|
测试目的:
验证发起方磁通道的数据编码符号率是否符合要求。
|
预置条件:按照图1进行连接。
|
测试步骤:
1.设置被测发起方重复无间断连续发送标准帧格式的PRBS数据;
2.将标准感应线圈置于被测发起方工作方向设备表面垂直距离0cm处,线圈平面与被测发起
方设备表面保持平行,且线圈中心位置与被测发起方设备中心位置重合;
3.通过标准感应线圈测量被测发起方磁信号的16个符号周期总时间为t;
4.根据f=16/t计算得到数据编码符号率f。
|
预期结果:
磁通道数据编码符号率为4kS/s,符号率容许偏差范围为士5%。
|
5.5.2 磁场信号强度测试
GB/T 33740—2017
预置条件:按照图1进行连接。
|
测试步骤:
1.设置被测发起方连续重复不间断地发送PRBS数据,测量其中的全“1”数据对应的磁场信号
强 度 ;
2.将标准感应线圈置于被测发起方工作方向设备表面垂直待测距离处,线圈平面与被测发起方
设备表面保持平行,且线圈中心位置与被测发起方设备中心位置重合;
3.通过标准感应线圈分别测量被测发起方工作方向设备表面垂直距离0cm处和10
cm处的磁
感应电压峰峰值Vp,并由Hp=5.4*Vp计算相应位置的发起方磁场信号强度。
|
预期结果:
以被测发起方设备工作位置中心为基准,工作方向设备表面垂直距离0
cm处磁场信号强度峰值 应不小于160 A/m且不大于300 A/m;设备表面垂直距离10
cm处磁场信号强度峰值应小于
4.2 A/m。 |
5.5.3 磁场信号符号周期抖动测试
测试项目:磁场信号符号周期抖动
|
测试目的:
验证发起方磁通道的磁场信号符号周期抖动是否符合要求。
|
预置条件:按照图1进行连接。
|
测试步骤:
1.标准感应线圈测量位置位于被测发起方工作方向设备表面垂直距离0cm处,线圈平面与设
备表面保持平行,且中心位置与被测发起方设备中心位置重合;
2.设置被测发起方连续不间断发送标准帧格式的PRBS数据;
3.通过示波器采集标准感应线圈感应的磁场信号,并设置示波器为"上升/下降时间"触发模式,
读取触发点后第三个过零点的时间抖动。
|
预期结果:
磁场信号符号周期抖动应不大于60 μs。
|
5.6 响应方磁通道测试项目
5.6.1 磁场信号强度门限测试
测试项目:磁场信号强度门限
|
测试目的:
验证响应方的磁场信号强度门限是否符合要求。
|
GB/T 33740—2017
测试步骤:
1.设置标准发起方连续不间断发送标准帧格式的PRBS数据;
2.将标准感应线圈置于标准发起方工作方向区域,线圈平面与标准发起方设备表面保持平行,
且线圈中心位置与标准发起方设备中心位置重合;
3.通过标准感应线圈确定被测磁场信号强度给定值所对应的标准发起方工作方向设备表面垂
直距离 ;
4.将被测响应方置于步骤3所确定的距离位置处,并测试被测响应方是否能够与标准发起方建
立并保持连接;
5.重复步骤3到4,分别测试在磁场信号强度为6.7A/m和4.2
A/m处被测响应方的连接状态,
应分别符合技术要求。
|
预期结果:
被测响应方设备置于标准发起方设备的磁场信号工作区域,在标准发起方磁场信号强度峰值为
6.7A/m处,被测响应方应能够与标准发起方建立并保持连接;被测响应方设备置于标准发起方设备
的磁场信号工作区域,在标准发起方磁场信号强度峰值为4.2A/m处,响应方应不能够与发起方建
立或保持连接。
|
5.7 发起方/响应方射频通道测试项目
5.7.1 发射功率测试
测试项目:发射功率
|
测试目的:
验证发起方或响应方的射频发射功率是否符合要求。
|
预置条件:
1.按照图3进行连接;2.在屏蔽室环境下进行测试。
|
测试步骤:
1.将2.45 GHz天线接口通过射频电缆连接到频谱分析仪;
2.设置被测设备以最大功率通过射频通道发送PRBS数据;
3.测试射频信号峰值功率;
4.重复步骤2到3,对中心频率为2468 MHz、2434
MHz、2401MHz的三个信道分别进行测试。 |
预期结果:
各射频信道发射功率最大不得超过+3 dBm。
|
GB/T 33740—2017
5.7.2 频率容限测试
测试项目:频率容限
|
测试目的:
验证发起方或响应方的射频频率容限是否符合要求。
|
预置条件:
1.按照图3进行连接;2.在屏蔽室环境下进行测试。
|
测试步骤:
1.将2.45GHz天线接口通过射频电缆连接到频谱分析仪;
2.设置被测设备通过射频通道重复发送0x55数据;
3.通过频谱分析仪测量射频通道信号的中心频率Ft,并测量Ft在一个数据帧传输时间内的累
计漂移量;
4.重复步骤3,对中心频率为2468 MHz、2434
MHz、2401MHz的三个信道分别进行测试。
|
预期结果:
发射载波的初始中心频率Ft应在本信道标称中心频率Fc的±75kHz频率范围内,即:
Fc-75 kHz≤Ft≤Fc+75 kHz。
注:土75 kHz不包括数据发送过程中的频率漂移。
在一个数据帧传输时间内,发射载波中心频率相对于载波初始中心频率发生的累积漂移量应在
+20 kHz之内。
|
5.7.3 调制参数测试
测试项目:调制参数
|
测试目的:
验证发起方或响应方的射频调制参数是否符合要求。
|
预置条件:
1.按照图3进行连接;2.在屏蔽室环境下进行测试。
|
测试步骤:
调制参数测试方法为:
1.将2.45 GHz天线接口通过射频电缆连接到频谱分析仪;
2.设置被测设备通过射频通道重复发送0x0F数据;
3.通过频谱分析仪测量数据序列传输中的频率偏移幅度为Fd;
4.设置被测设备通过射频通道重复发送0xAA数据;
5.通过频谱分析仪测量数据序列传输中的频率偏移幅度为Fmin;
6.重复步骤2到5,对中心频率为2468 MHz,2434 MHz,2401
MHz的三个信道分别进行测试。
|
GB/T 33740—2017
5.7.4 带内杂散测试
测试项目:带内杂散
|
测试目的:
验证发起方或响应方的射频带内杂散是否符合要求。
|
预置条件:
1.按照图3进行连接;2.在屏蔽室环境下进行测试。
|
测试步骤:
1.将2.45GHz天线接口通过射频电缆接到频谱分析仪;
2.设置被测设备通过被测信道即第M信道发送PRBS数据;
3.通过频谱分析仪测量中心频率相邻第N信道的功率值总和,即为相邻第N信道上的杂散
功 率 ;
4.重复步骤3,完成所有相邻信道的测试;
5.重复步骤3到4,对中心频率为2468 MHz,2434
MHz,2401MHz的三个信道分别进行
测 试 。
|
预期结果:
当射频信号发射设备在第M信道发射包含伪随机二进制序列(PRBS)数据的射频信号时,相邻
第N信道上的杂散功率应小于如下表所示的最大限制。
发射频谱带内杂散
2MHz( |M-N |=2) |
—20 dBm
|
≥3MHz( |M-NI≥3)
|
-30 dBm
|
|
6 协议测试
6.1 测试对象
本标准针对发起方和响应方分别进行协议测试。
6.2 测试环境
按照图4所述方式,对响应方协议测试环境进行连接配置,按照图5所述方式,对发起方协议测试
环境进行连接配置。
GB/T 33740—2017
除非另有说明,测试应在常温、相对湿度为40%~60%之间的环境下进行。
6.3 默认容许误差
除非另有说明,测试过程中空口交互协议的时间指标默认容许误差为±30%。
6.4 协议测试仪
本标准使用响应方测试仪 tTester 和发起方测试仪 iTester
两种测试装置,分别用于响应方 DUT
和发起方 DUT 的测试。
iTester和 tTester应能测量两次 I/O 之间的时间,并能记录和检查来自 DUT
的数据。
iTester和 tTester 的空中接口物理层和链路层必须符合本系列标准要求。
iTester和 tTester应能够按照本系列标准的要求产生 I/O 字符流。
6.5 RFU 域
如果 RFU 域未设置为其默认值,则测试失败,且认为 DUT 不符合规定。
6.6 测试命令
本标准定义的测试命令见附录C。
DUT 必须支持 ECHO 数据交易指令APDATA REQ(t1)、APDATA REQ(t2)。
6.7 协议测试配置
6.7.1 响应方协议测试配置
使用响应方测试仪tTester执行测试命令,接收并检查 DUT
的响应。测试配置如图4所示。
注意:在进行各项测试之前务必将DUT 置于响应方测试仪tTester的工作区域。
style="width:3.6in;height:3.58056in" />
图 4 响应方测试配置示意图
6.7.2 发起方协议测试配置
使用发起方测试仪 iTester通过串口线与 DUT 连接,并控制 DUT
执行测试命令,iTester模拟响
应方接收并检查 DUT 的请求。测试配置如图5所示。
注意:在进行各项测试之前务必将发起方测试仪iTester置于 DUT 的工作区域。
GB/T 33740—2017
style="width:4.6868in;height:3.56664in" />iTester
测试命令 测试响应 串口命令
DUT
图 5 发起方测试配置示意图
6.8 响应方协议测试项目
6.8.1 激活测试
测试项目:激活测试
|
测试目的:
验证响应方DUT在激活阶段的数据格式、逻辑操作和响应时间是否符合要求。
|
预置条件:按照图4进行连接。
|
测试步骤:
测试子项1:
子项目的:测试DUT收到无效的激活命令和正确的激活命令时,响应是否正确。
子项步骤:
1.tTester发送无效的激活命令INQUIRY(e)oo;
2.tTester在8
ms内接收DUT的响应,若收到DUT的射频消息,则测试Fail,否则继续第
3 步 ;
3.tTester发送有效的激活命令INQUIRY(t)oo;
4.tTester在8ms内接收DUT的响应ATI,若未收到DUT的ATI响应,则测试Fail,否则
继续第5步;
5.tTester检查ATI数据格式。
测试流程1
|
|
响应方测试仪tTester DUT
|
|
|
INQUIRY(e)oo
Mute
|
|
INQUIRY(t)ao
ATI
|
子项预期结果:见"预期结果"。
|
预期结果:
1.执行测试子项1,DUT 应按照测试流程进行响应,不出现测试Fail的情况。
2.ATI 的数据格式与下表一致。
6.8.2 连接测试
测试项目:连接测试
|
测试目的:
验证响应方DUT在建立连接阶段的数据格式、逻辑操作和响应时间是否符合要求。
|
预置条件:按照图4进行连接。
|
测试步骤:
测试子项1:
子项目的:测试DUT在连接阶段收到数据交换请求时响应是否正确。
子项步骤:
1.tTester发送激活命令INQUIRY(t)oo;
2.tTester在8ms内接收DUT的激活响应ATIo;
3.tTester发送APDATA REQ(t1)oo;
4.tTester在500ms内接收DUT的响应,若收到DUT的射频消息则测试Fail,否则测试结束。
测试流程1
INQUIRY(t)o
|
ATI
|
APDATA REQ(t1)o
|
Mute
|
|
GB/T 33740—2017
style="width:12.36011in" />
GB/T 33740—2017
|
响应方测试仪tTester
|
DUT
|
|
|
INQUIRY(t)3
|
ATIs
|
|
|
CONNECT REQ(e)o3
|
Mute
|
|
|
子项预期结果:见"预期结果"。
测试子项5:
子项目的:测试 DUT 在连接阶段收到有效的连接请求时响应是否正确。
子项步骤:
1.tTester发送激活命令 INQUIRY(t)o₄ ;
2.tTester在 8 ms 内接收DUT 的激活响应 ATI₄ ;
3.tTester发送有效的连接命令 CONNECT REQ(t)o;
4.tTester在8 ms 内接收 DUT 的连接响应 CONNECT RSP,tTester
RSP₄ 的数据格式。
测试流程5
|
检查 CONNECT
|
|
|
响应方测试仪tTester
|
DUT
|
|
|
INQUIRY(t)o4
|
ATI
|
|
|
CONNECT REQ(t)o₄
|
CONNECT RSP
|
|
|
子项预期结果:见"预期结果"。
|
|
|
|
预期结果:
1.执行测试子项1~5,DUT 应按照测试流程进行响应,不出现测试
Fail的情况。
2.CONNECT RSP 数据格式符合下表要求:
|
|
|
字段
|
值
|
|
|
Rfu(4 bit)
|
0
|
|
|
FormatType(4 bit)
|
8
|
|
|
Status(8 bit)
|
0x00或者0xD0~0xFF
|
|
|
MsgCode(8 bit)
|
18
|
|
|
MsgLen(16 bit)
|
24
|
|
|
Result(1 Byte)
|
0x00或0x01
|
|
|
RootKeylndex(1 Byte)
|
0x00
|
|
|
SessionKey(1 Byte)
|
0x01
|
|
|
EncAlg(2 Byte)
|
0x0100
|
|
|
SDInfo(5 Byte)
|
自定义
|
|
|
SDRand(8 Byte)
|
随机数
|
|
|
Reseved(6 Byte)
|
0
|
|
|
CheckSum(2 Byte)
|
对消息头和消息体数据进行CheckSum校验。
|
|
|
GB/T 33740—2017
6.8.3 数据交换测试
测试项目:数据交换测试
|
测试目的,
验证响应方DUT在数据交易阶段的数据格式、逻辑操作和响应时间是否符合要求。
|
预置条件:按照图4进行连接。
|
测试步骤:
测试子项1:
子项目的:测试DUT在数据交易阶段接收到无效的数据交换命令时响应是否正确。
子项步骤:
1.tTester发送激活命令INQUIRY(t)oo;
2.tTester在8 ms内接收DUT的激活响应ATIo;
3.tTester发送有效的连接命令CONNECT REQ(t)oo;
4.tTester在8ms内接收DUT的连接响应CONNECT RSPoo;
5.tTester在MC通道持续发送CHECK1 REQ(t)或者CHECK2 REQ(t)oo;
6.tTester发送无效的数据交换命令APDATA REQ(e)oo;
7.tTester在500ms内接收DUT的响应;
8.tTester发送数据交换命令APDATA REQ(t1)oo;
9.tTester在500ms内接收DUT的响应,若收到DUT的射频消息则测试Fail,否则测试结束。
测试流程1
INQUIRY(t)oo
ATI
|
CONNECT REQ(t)o
CONNECT RSP₀
|
CHECK1 REQ(t)。or CHECK2 REQ(t)o
|
APDATA REQ(e)o
Mute
|
APDATA REQ(t1)
Mute
|
子项预期结果:见"预期结果"。
测试子项2:
子项目的:测试DUT在数据交易阶段接收到数据交换命令(单包)时响应是否正确。
子项步骤:
1.tTester发送激活命令INQUIRY(t)a;
2.tTester在8ms内接收DUT的激活响应ATIoi;
|
GB/T 33740—2017
GB/T 33740—2017
GB/T 33740—2017
|
响应方测试仪iTester DUT
|
|
INQUIRY(t)o4
ATI
|
CONNECT REQ(t)
CONNECT RSP
_
|
CHECK1 REQ(e)o
|
APDATA REQ(t)₄
APDATA RSP
|
子项预期结果:见"预期结果"。
测试子项6:
子项目的:测试 DUT 在数据交易阶段接收到CDC 错误的连接确认消息 CHECK2
REQ(e) 时,
是否正确地更新消息的状态 Status。
子项步骤:
1.tTester 发送激活命令 INQUIRY(t)os;
2.tTester在 8ms 内接收 DUT 的激活响应 ATIs;
3.tTester发送有效的连接命令 CONNECT REQ(t)o;
4.tTester在 8 ms 内接收 DUT 的连接响应 CONNECT RSPos;
5.tTester发送 CHECK2 REQ(e)os;
6.tTester 发送 APDATA REQ(t1)os;
7.tTester在500ms 内接受 APDATA RSPos, 检查其Status字段的值。
测试流程6
INQUIRY(t)os
ATIs
|
CONNECT REQ(t)s
CONNECT RSPs
|
CHECK2 REQ(e)
|
APDATA REQ(t1)。s
APDATA RSP
_
|
子项预期结果:见"预期结果"。
测试子项7:
子项目的:测试 DUT 在数据交易阶段收到处理时间超过500 ms
的数据交换指令时,是否正确
地响应 LTW。
子项步骤:
1.tTester发送激活命令 INQUIRY(t)o;
2.tTester在8 ms 内接收DUT 的激活响应 ATIo₆ ;
3.tTester发送有效的连接命令 CONNECT REQ(t)os;
|
GB/T 33740—2017
|
响应方测试仪tTester DUT
|
|
|
INQUIRY(t)os
ATI₆
|
|
|
CONNECT REQ(t)o₆
CONNECT RSP
_
|
|
|
CHECK1 REQ(t)o or CHECK2 REQ(t)o₆
|
|
|
|
APDATA RSP
_
|
|
子项预期结果:见"预期结果"。
|
预期结果:
1. 执行测试子项1~7,DUT
应按照测试流程进行响应,不出现测试Fail的情况。 2.APDATA RSP₀ 和 APDATA
RSPo₅ 的 Status 字段值为0x01。
3.APDATA RSPo 的数据格式符合下表要求:
|
|
字段
|
值
|
|
Rfu(4 bit)
|
0
|
|
FormatType(4 bit)
|
8
|
|
Status(8 bit)
|
0x00或者0xD0~0xFF
|
|
MsgCode(8 bit)
|
20
|
|
MsgLen(16 bit)
|
24
|
|
EncPayLoad(24 Byte)
|
与APDATA REQ(t1)中EncPayLoad匹配,详见附录C
|
|
CheckSum(2 Byte)
|
对消息头和消息体数据进行CheckSum校验。
|
4.APDATA RSP₂ 的数据格式符合下表要求:
|
|
字段
|
值
|
|
|
Rfu(4 bit)
|
0
|
|
|
FormatType(4 bit)
|
8
|
|
|
Status(8 bit)
|
除0x01、0x02、0x82的其他数值
|
|
|
MsgCode(8 bit)
|
20
|
|
|
MsgLen(16 bit)
|
248
|
|
|
EncPayLoad(248 Byte)
|
与APDATA REQ(t2)o2中EncPayLoad相同
|
|
|
CheckSum(2 Byte)
|
对消息头和消息体数据进行CheckSum校验。
|
|
5.APDATA RSPo的数据格式符合下表要求:
Rfu(4 bit)
|
0
|
FormatType(4 bit)
|
8
|
Status(8 bit)
|
0x00或者0xD0~0xFF
|
MsgCode(8 bit)
|
20
|
MsgLen(16 bit)
|
自定义,与EncPayLoad匹配,不超过288
|
EncPayLoad(小于288 Byte)
|
自定义,与DUT匹配
|
CheckSum(2 Byte)
|
对消息头和消息体数据进行CheckSum校验。
|
6.LTW。 的数据格式符合下表要求:
Rfu(4 bit)
|
0
|
Status(8 bit)
|
0x00或者0xD0~0xFF
|
MsgLen(16 bit)
|
2
|
Reserved(1 Byte)
|
0
|
6.8.4 链路维持测试
测试项目:链路维持测试
|
测试目的:
验证响应方DUT在链路维持阶段的数据格式、逻辑操作和响应时间是否符合要求。
|
预置条件:按照图4进行连接。
|
测试步骤:
测试子项1:
子项目的:测试DUT在链路维持阶段收到无效的维持连接请求时,是否响应正确。
子项步骤:
1.tTester发送激活命令INQUIRY(t)oo;
2.tTester在8ms内接收激活响应ATIo;
3.tTester发送的连接命令CONNECT REQ(t)oo;
4.tTester在8ms内接收连接响应CONNECT RSPoo;
5.tTester在MC通道持续发送CHECK1 REQ(t)或者CHECK2 REQ(t)oo;
6.tTester发送无效的LINKCTL REQ(e)oo;
|
GB/T 33740—2017
7.tTester在 8 ms 内接收DUT 响应,若收到 DUT
的射频消息则测试Fail,否则继续第8步;
8.tTester发送 APDATA REQ(t1)oo;
9.tTester在 8 ms 内接收 DUT 响应,若收到 DUT
的射频消息则测试Fail,否则测试结束。
测试流程1
DUT
INQUIRY(t)oo
ATIo
CONNECT REQ(t)
CONNECT RSP
CHECK1 REQ(t) or CHECK2 REQ(t)0
LINKCTL REQ(e)。。
Mute
APDATA REQ(t1)
Mute
子项预期结果:见“预期结果”。
测试子项2:
子项目的:测试DUT
在链路维持阶段且磁通道没有消息的条件下,连续三次收到维持连接请
求,对第三次维持连接请求的响应是否正确。
子项步骤:
1.tTester 发送激活命令INQUIRY(t)oi;
2.tTester 在 8 ms 内接收激活响应 ATI;
3.tTester 发送连接命令 CONNECT REQ(t)o;
4.tTester在8 ms 内接收连接响应 CONNECT RSPo;
RSPo₁;
|
|
6.tTester在44 ms 后发送 LINKCTL REQ(t)o,
|
之后在8 ms 内接收 DUT 响应 LINKCTL
|
RSPo;
7.tTester在44 ms 后发送 LINKCTL REQ(t)。, 之后在8 ms 内接收 DUT 响应
LINKCTL
RSP₀ , 检查 LINKCTL RSP 的数据格式。
测试流程2
响应方测试仪tTester DUT
INQUIRY(t)o
ATI
CONNECT REQ(t)
CONNECT RSP
GB/T 33740—2017
|
响应方测试仪tTester DUT
|
|
LINKCTL REQ(t)
LINKCTL RSP
|
LINKCTL REQ(t)oi
LINKCTL RSP
|
INKCTL REQ(t)o₁
LINKCTL RSP₀
|
子项预期结果:见“预期结果”。
测试子项3:
子项目的:测试DUT 在链路维持阶段且磁通道存在冲突检测请求CHECK1 REQ
的条件下,收
到多次维持连接请求时响应是否正确,之后收到数据交换指令是否响应正确。
子项步骤:
1.tTester发送激活命令 INQUIRY(t)o2;
2.tTester在 8 ms 内接收激活响应 ATI₂ ;
3.tTester 发送连接命令CONNECT REQ(t)o2;
4.tTester在 8 ms 内接收连接响应 CONNECT RSPo₂ ;
5.tTester在 MC 通道持续发送CHECK1 REQ(t)o2;
RSPo₂;
|
|
7.tTester 在44 ms 后发送 LINKCTL REQ(t)o₂ ,
|
之 后 在 8 ms 内收 DUT 响应 LINKCTL
|
RSPo₂;
|
|
8.tTester在44 ms 后发送 LINKCTL REQ(t)2,
|
之 后 在 8 ms 内收 DUT 响应 LINKCTL
|
RSPo₂ , 检查 LINKCTL RSP₀₂ 的数据格式;
9.tTester 发送 APDATA REQ(t1)o2;
10.tTester在500 ms 内接收DUT 响应的 APDATA RSP₂。
测试流程3
INQUIRY(t)o2
ATI2
|
CONNECT REQ(t)2
CONNECT RSP2
|
CHECK1 REQ(t)₂
LINKCTL REQ(t)2 LINKCTL RSP₀₂
|
LINKCTL REQ(t)o2
LINKCTL RSP2
|
|
GB/T 33740—2017
|
响应方测试仪tTester DUT
|
|
|
INKCTL REQ(t)o2
LINKCTL RSP₂
|
|
|
APDATA REQ(t1)o2
APDATA RSPo₂
|
|
|
子项预期结果:见"预期结果"。
测试子项4:
子项目的:测试 DUT 在链路维持阶段且磁通道存在连接确认消息CHECK2 REQ
的条件下,收
到多次维持连接请求时响应是否正确,之后收到数据交换指令是否响应正确。
子项步骤:
1.tTester 发送激活命令 INQUIRY(t)os;
2.tTester在 8 ms 内接收激活响应 ATIs;
3.tTester发送连接命令CONNECT REQ(t)os;
4.tTester在 8 ms 内接收连接响应 CONNECT RSP₃ ;
5.tTester在 MC 通道持续发送CHECK2 REQ(t)o3;
RSPo3;
|
|
7.tTester在44 ms 后发送 LINKCTL REQ(t)o3,
|
之后在8 ms 内接收 DUT 响应 LINKCTL
|
RSPo3;
|
|
8.tTester在44 ms 后发送 LINKCTL REQ(t)o3,
|
之后在8 ms 内接收 DUT 响应 LINKCTL
|
RSP³, 检查 LINKCTL RSP3 的数据格式;
9.tTester 发送 APDATA REQ(t1)o3;
10.tTester 在500 ms 内接收 DUT 响应的 APDATA RSPos。
测试流程4
|
|
|
响应方测试仪tTester DUT
|
|
|
INQUIRY(t)o3
ATI
|
|
|
CONNECT REQ(t)o3
CONNECT RSP₃
_
|
|
|
CHECK2 REQ(t)o3
LINKCTL REQ(t)o
LINKCTL RSP
|
|
|
LINKCTL REQ(t)o3
LINKCTL RSP₀₃
|
|
|
LINKCTL REQ(t)o3
LINKCTL RSP₃
|
|
|
APDATA REQ(t1)o3
APDATA RSP
|
|
|
GB/T 33740—2017
GB/T 33740—2017
|
响应方测试仪tTester DUT
|
|
|
CONNECT REQ(t)os
CONNECT RSP
|
|
|
CHECK2 REQ(e)os
LINKCTL REQ(t)o
LINKCTL RSP
|
|
子项预期结果:见"预期结果"。
预期结果:
1. 执行测试子项1~6,DUT
应按照测试流程进行响应,不出现测试Fail的情况。
2.LINKCTL RSP₂ 、LINKCTL RSP 数据格式符合下表要求。
3.LINKCTL RSP、LINKCTL RSP₀ 和 LINKCTL RSP 的 Status
值为0x01,其余内容与下
表相同:
|
|
字段
|
值
|
|
|
Rfu(4 bit)
|
0
|
|
|
FormatType(4bit)
|
8
|
|
|
Status(8bit)
|
0x00或者0xD0~0xFF
|
|
|
MsgCode(8bit)
|
24
|
|
|
MsgLen(16 bit)
|
2
|
|
|
RandData(1 byte)
|
随机
|
|
|
Reserved(1 byte)
|
0
|
|
|
CheckSum(2 byte)
|
对消息头和消息体数据进行CheckSum校验。
|
|
|
6.8.5 关闭连接测试
测试项目:关闭连接测试
|
测试目的:
验证响应方DUT在关闭连接阶段的数据格式、逻辑操作和响应时间是否符合要求。
|
预置条件:
按照图4进行连接。
|
测试步骤:
测试子项1:
子项目的:测试DUT结束阶段收到错误的关闭连接请求时,响应是否正确。
子项步骤:
1.tTester发送激活命令INQUIRY(t)oo;
|
GB/T 33740—2017
GB/T 33740—2017
style="width:12.37332in" />
GB/T 33740—2017
子项预期结果:见"预期结果"。
预期结果:
1. 执行测试子项1~3,DUT 应按照测试流程进行响应,不出现测试Fail
的情况。
2.CLOSE RSP 数据格式符合下表要求:
Rfu(4 bit)
|
0
|
FormatType(4bit)
|
8
|
Status(8bit)
|
0x00或者0xD0~0xFF
|
MsgCode(8bit)
|
27
|
MsgLen(16 bit)
|
4
|
CloseResult (1 byte)
|
0
|
Reserved(3 byte)
|
0
|
CheckSum(2 byte)
|
对消息头和消息体数据进行CheckSum校验。
|
6.8.6 冲突机制测试
测试项目:冲突机制测试
|
测试目的:
验证响应方DUT冲突检测机制的数据格式、逻辑操作和响应时间是否符合要求。
|
预置条件:按照图4进行连接。
|
测试步骤:
测试子项1:
子项目的:验证DUT在未连接状态下收到CHECK1
REQ时,是否在冲突响应时间窗(4 ms)内
随机地发送冲突响应消息。
子项步骤:
1.tTester持续发送CHECK1 REQ(t)oo;
|
GB/T 33740—2017
|
|
CHECK1 REQ(t)o
CHECK RSP
_
|
|
子项预期结果:见"预期结果"。
|
预期结果:
1.执行以上测试子项1,DUT
应按照测试流程进行响应,不出现测试Fail的情况。
2.测试过程中不出现 Fail情况。
3.CHECK RSP 的数据格式符合下表要求。
|
|
字段
|
值
|
|
Rfu(4 bit)
|
0
|
|
FormatType(4 bit)
|
8
|
|
Status(8 bit)
|
0x01
|
|
MsgCode(8 bit)
|
24
|
|
MsgLen(16 bit)
|
8
|
|
RandData(1 byte)
|
随机数
|
|
Reserved(7 byte)
|
0
|
|
CheckSum(2 byte)
|
对消息头和消息体数据进行CheckSum校验。
|
|
6.8.7 通道绑定测试
测试项目:通道绑定测试
|
测试目的:
验证响应方DUT磁通道和射频通道之间的绑定机制是否有效,即验证DUT在维持连接、数据
交易、激活、连接等不同阶段,未接收到磁通道消息的情况下,DUT在射频通道上的响应是否符合
要 求 。
|
预置条件:按照图4进行连接。
|
测试步骤:
测试子项1:
子项目的:测试DUT维持连接阶段未接收到磁通道消息时,是否正确更新响应消息的状态Sta-
tus。
子项步骤:
1.tTester发送激活命令INQUIRY(t)oo;
2 . tTester在8ms内接收DUT的响应ATI;
|
GB/T 33740—2017
GB/T 33740—2017
|
响应方测试仪tTester DUT
|
|
INQUIRY(t)o2
关闭磁场
|
Mute
|
|
子项预期结果:见“预期结果”。
测试子项4:
子项目的:测试 DUT
连接阶段未接收到磁通道消息时,响应是否符合要求。
子项步骤:
1.tTester 发送激活命令INQUIRY(t)os;
2.tTester在8 ms 内接收 DUT 的响应 ATI₃ ;
3.tTester关闭磁场;
4.tTester 发送 CONNECT REQ(t)o₃ ;
5.tTester在 8 ms 内接收DUT 的响应,若收到 DUT
的射频消息则测试Fail,否则测试结束。
测试流程4
INQUIRY(t)o3
ATI
|
关闭磁场
|
CONNECT REQ(t)os
Mute
|
子项预期结果:见"预期结果"。
|
预期结果:
1. 执行测试子项1~4,DUT
应按照测试流程进行响应,不出现测试Fail的情况。 2.LINKCTL RSP 的
Status字段为0x82 或 0x02 或 0x01。
3.APDATA RSP₀ 的 Status 字段为0x82 或 0x02。
|
6.8.8 超时时间测试
测试项目:超时时间测试
|
测试目的:
验证响应方DUT在连接阶段、链路维持阶段、数据交易阶段的超时时间是否符合要求。
|
预置条件:按照图4进行连接。
|
GB/T 33740—2017
GB/T 33740—2017
GB/T 33740—2017
预期结果:
执行测试子项1~6,DUT 应按照测试流程进行响应,不出现测试
Fail的情况。
|
GB/T 33740—2017
6.8.9 加密算法验证
测试项目:加密算法验证
|
测试目的:
验证响应方 DUT 支持的加密算法是否符合要求。
|
预置条件:按照图4进行连接。根据 DUT
支持的加密算法选择一个或多个测试子项进行测试。
|
测试步骤:
测试子项1:
子项目的:测试DUT 的 3DES-ECB 算法。
子项步骤:
1.tTester 发送激活命令 INQUIRY(t)oo;
2.tTester在 8 ms 内接收 DUT 的响应 ATIoo;
3.tTester 在收到 DUT 的 响 应 ATI 后发送 CONNECT REQ(t) ,EncAlg
字段的值
为 0x0001;
4.tTester在8 ms 内接收 DUT 的 CONNECT RSPoo;
5.tTester 在 MC 通道持续发送 CHECK1 REQ(t) 或者CHECK2 REQ(t)oo;
6.tTester分析 CONNECT RSPo, 若 EncAlg 字段的值为0x0000,则说明DUT
不支持该算法,
测试结束;若为0x0001 则进入第7步,否则若为其他值则测试 Fail;
7.tTester 发送 APDATA REQ(t1)oo;
8.tTester在500 ms 内接收 APDATA RSPo,
核对其数据的加密算法是否正确。
测试流程1
INQUIRY(t)oo
ATIo
|
CONNECT REQ(t)
CONNECT RSP
|
CHECK1 REQ(t)。or CHECK2 REQ(t)o
|
APDATA REQ(t1)oo
APDATA RSP
|
子项预期结果:见“预期结果”。
测试子项2:
子项目的:测试DUT 的 3DES-CBC 算法。
子项步骤:
1.tTester发送激活命令INQUIRY(t)o;
2.tTester在8 ms 内接收 DUT 的响应 ATI;
|
GB/T 33740—2017
|
响应方测试仪iTester DUT
|
|
INQUIRY(t)o2
ATI
|
CONNECT REQ(t)2
CONNECT RSP
|
GB/T 33740—2017
|
响应方测试仪iTester DUT
|
|
CHECK1 REQ(t)o2 or CHECK2 REQ(t)。2
|
APDATA REQ(t1)o2 APDATA RSPo2
Or结束
|
子项预期结果:见"预期结果"。
测试子项4:
子项目的:测试 DUT 的 AES-CBC 算法。
子项步骤:
1.tTester 发送激活命令 INQUIRY(t)os;
2.tTester在8 ms 内接收 DUT 的响应 ATI₃ ;
3.tTester 在收到 DUT 的响应 ATI 后发送CONNECT REQ(t)₃,EncAlg
字段的值为0x0008;
4.tTester 在 8 ms 内接收到 DUT 的 CONNECT RSP₃ ;
5.tTester 在 MC 通道持续发送 CHECK1 REQ(t)o 或者CHECK2 REQ(t)o3;
6.tTester分析 CONNECT RSPo₃ , 若 EncAlg 字段的值为0x0000 则说明 DUT
不支持该算法,
测试结束;若为0x0008 则进入第7步,否则若为其他值则测试 Fail;
7.tTester发送 APDATA REQ(t1)os;
8.tTester在500 ms 内接收 APDATA RSP³,
核对其数据的加密算法是否正确。
测试流程4
INQUIRY(t)o3
ATI3 |
CONNECT REQ(t)a3
CONNECT RSP₃ |
CHECK1 REQ(t)a or CHECK2 REQ(t)oa
|
APDATA REQ(t1)o3
APDATA RSPo₃
Or结束 |
子项预期结果:见"预期结果"。
测试子项5:
子项目的:测试 DUT 的 SM4-ECB 算法。
子项步骤:
1.tTester 发送激活命令INQUIRY(t)o;
2.tTester在 8 ms 内接收 DUT 的响应 ATI₄ ;
3.tTester 在收到 DUT 的响应 ATI 后发送 CONNECT REQ(t) ,EncAlg
字段的值
为 0x0010;
4.tTester 在8 ms 内接收到 DUT 的 CONNECT RSP₄ ;
5.tTester 在 MC 通道持续发送 CHECK1 REQ(t)。 或者CHECK2 REQ(t)o;
6.tTester分析 CONNECT RSP, 若 EncAlg 字段的值为0x0000 则说明 DUT
不支持该算法,
测试结束;若为0x0010 则进入第7步,否则若为其他值则测试 Fail;
7.tTester 发送 APDATA REQ(tl)。;
|
style="height:0.39314in" />style="height:0.39314in" />8.tTester 在500 ms 内接收 APDATA RSP,
核对其数据的加密算法是否正确。
测试流程5
INQUIRY(t)
ATI |
CONNECT REQ(t)o
CONNECT RSP₀
_
|
CHECK1 REQ(t)or CHECK2 REQ(t) →
|
APDATA REQ(t1)
APDATA RSP₄
Or结束 |
子项预期结果:见"预期结果"。
测试子项6:
子项目的:测试 DUT 的 SM4-CBC 算法。
子项步骤:
1.tTester 发送激活命令 INQUIRY(t)os;
2.tTester在 8 ms 内接收 DUT 的响应 ATIs;
3.tTester 在收到DUT 的响应ATI 后发送CONNECT REQ(t)s,EncAlg
字段的值为0x0020;
4.tTester在8 ms 内接收到 DUT 的 CONNECT RSPos;
5.tTester 在 MC 通道持续发送CHECK1 REQ(t) 或者CHECK2 REQ(t)o5;
6.tTester 分析 CONNECT RSPs, 若 EncAlg 字段的值为0x0000 则说明 DUT
不支持该算法,
测试结束;若为0x0020 则进入第7步,否则若为其他值则测试 Fail;
7.tTester 发送 APDATA REQ(t1)os;
8.tTester 在500 ms 内接收 APDATA RSPos, 检查验证其数据的加密算法。
测试流程6
|
INQUIRY(t)os
ATL |
|
CHECK1 REQ(t)oor CHECK2 REQ(t)os
|
|
2. 执行测试子项1~6,所有数据的加密算法验证通过。
GB/T 33740—2017
6.8.10
频点范围测试
测试项目:频点范围测试
|
测试目的:
验证响应方DUT的频点范围是否符合要求。
|
预置条件:按照图4进行连接。
|
测试步骤:
测试子项1:子项目的:测试DUT的工作频点是否正确。
子项步骤:
1.tTester发送激活命令INQUIRY(t),设置其IDm使得ATI的频点为2401MHz;
2.tTester在8ms内接收激活响应ATI,若没有收到ATI则测试Fail;
3.重复63次执行第2步,每重复一次设置其IDm使得ATI的频点增加1 MHz。
测试流程1
子项预期结果:见"预期结果"。
|
预期结果:
执行上述测试子项1,DUT应按照测试流程进行响应,不出现测试Fail的情况。
|
6.9 发起方协议测试项目
6.9.1 激活测试
测试项目:激活测试
|
测试目的:
验证发起方DUT在激活阶段的数据格式、逻辑操作和响应时间是否符合要求。
|
预置条件:按照图5进行连接。
|
测试步骤:
测试子项1:
子项目的:测试DUT在激活阶段收到无效的ATI时,处理是否正确。
子项步骤:
1.DUT发送INQUIRYo,iTester接收并检查INQUIRYo的数据格式;
2.iTester在8ms内响应无效的ATI(e)oo;
3.iTester在8ms内接收来自DUT的命令,若未收到任何命令,或者只收到INQUIRY命令,
则测试结束,否则测试Fail。
|
GB/T 33740—2017
|
DUT 发起方测试仪iTester
|
|
INQUIRY
ATI(e)a。 |
Mute or INQUIRYoo
|
子项预期结果:见“预期结果”。
测试子项2:
子项目的:测试DUT 在激活阶段接收超时后处理是否正确。
子项步骤:
1.DUT 发送 INQUIRYo₁ ;
2.iTester等待8 ms, 不作响应;
3.iTester在 8 ms 内接收来自 DUT 的命令,若未收到任何命令,或者只收到
INQUIRY₀ 命令,
则测试结束,否则测试 Fail。
测试流程2
INQUIRY₀
Mute |
Mute or INQUIRYo
|
子项预期结果:见"预期结果"。
测试子项3:
子项目的:测试 DUT 在激活阶段接收到有效的 ATI 时,处理是否正确。
子项步骤:
1.DUT 发送 INQUIRYo₂ ;
2.iTester在 8 ms 内响应有效的 ATI(t)oz;
3.iTester在 8 ms 内接收来自 DUT 的命令,若收到命令且为连接请求
CONNECT REQ₂ , 则
测试结束,否则测试 Fail。
测试流程3
INQUIRYo2
ATI(t)o2 |
CONNECT REQ
|
子项预期结果:见"预期结果"。
|
预期结果:
1. 执行测试子项1~3,DUT 应按照测试流程进行处理,不出现测试 Fail
的情况。 2.INQUIRYo 的数据格式符合下表要求:
|
|
字段
|
值
|
|
MsgCode(4 bit)
|
0
|
MsgLen(4 bit)
|
15
|
Rfu(4bit)
|
0
|
AccessVersion(4bit)
|
0x03
|
IDm(14 byte)
|
随机数
|
GB/T 33740—2017
6.9.2 连接测试
测试项目:连接测试
|
测试目的:
验证发起方 DUT
在建立连接阶段的数据格式、逻辑操作和响应时间是否符合要求。
|
预置条件:按照图5进行连接。
|
测试步骤:
测试子项1:
子项目的:测试 DUT 在连接阶段收到无效的连接响应时,处理是否正确。
子项步骤:
1.DUT 发送 INQUIRYao;
2.iTester在8 ms 内响应有效的 ATI(t)oo;
3.iTester在8 ms 内接收 DUT 的 CONNECT REQoo,iTester
检查消息的格式;
4.iTester在 8 ms 内响应无效的CONNECT RSP(e)oo;
5.iTester在100 ms 内接收来自 DUT 的命令,若未收到任何命令,或者收到
INQUIRY 或
CLOSE REQ 命令,则测试结束,否则测试 Fail。
测试流程1
INQUIRYmo
ATI(t)oo |
CONNECT REQ
— CONNECT RSP(e)o |
INQUIRYo or CLOSE REQor Mute
|
子项预期结果:见"预期结果"。
测试子项2:
子项目的:测试 DUT 在连接阶段接收超时后,处理是否正确。
子项步骤:
1.DUT 发送 INQUIRY。;
2.iTester在8 ms 内响应有效的 ATI(t)oi;
3.iTester在8 ms 内接收 DUT 的 CONNECT REQ;
4.iTester空闲等待8 ms, 不作响应;
5.iTester 在100 ms 内接收来自 DUT 的命令,若未收到任何命令,或者收到
INQUIRYo 或
CLOSE REQ 命令,则测试结束,否则测试 Fail。
|
GB/T 33740—2017
|
DUT 发起方测试仪iTester
|
|
INQUIRYo
ATI(t)oi |
CONNECT REQ
Mute |
INQUIRYoor CLOSE REQor Mute
_
|
子项预期结果:见"预期结果"。
测试子项3:
子项目的:测试 DUT 在连接阶段收到正常的连接响应时,处理是否正确。
子项步骤:
1.DUT 发 送 INQUIRY₂ ;
2.iTester在 8 ms 内响应有效的 ATI(t)o₂ ;
3.iTester在8 ms 内接收 DUT 的 CONNECT REQ;
4.iTester在 8 ms 内响应有效的CONNECT RSP(t)o2;
5.iTester在100 ms 内接收来自DUT 的命令,若收到 CHECK1 REQ 或 CHECK2
REQo 或
LINKCTL REQ 或 APDATA REQo 命令,则测试结束,否则测试Fail。
测试流程3
INQUIRYo2
ATI(t)o2 |
CONNECT REQ
CONNECT RSP(t)o2 |
CHECK1 REQor CHECK2 REQ
LINKCTL REQ or APDATA REQ
_ _
|
子项预期结果:见"预期结果"。
测试子项4:
子项目的:测试 DUT 在连接阶段是否判断连接结果。
子项步骤:
DUT 发 送 INQUIRY₀₃ ;
1.iTester在8 ms 内响应有效的 ATI(t)os;
2.iTester在 8 ms 内接收 DUT 的 CONNECT REQ;
3.iTester空8 ms 内响应有效的CONNECT RSPo₃,Result 值为0x01;
4.iTester在100 ms 内接收来自 DUT 的命令,若未收到任何命令,或者收到
INQUIRY₃ 或
CLOSE REQ 命令,则测试结束,否则测试 Fail。
|
GB/T 33740—2017
预期结果:
1.执行测试子项,DUT 应按照测试流程进行处理,不出现测试
Fail的情况。
2.CONNECT REQ 命令数据格式符合下表要求:
Rfu(4 bit)
|
0
|
FormatType(4bit)
|
8
|
Status(8bit)
|
0x00或者0xD0~0xFF
|
MsgCode(8bit)
|
17
|
MsgLen(16 bit)
|
24
|
InitiatorType(1 byte)
|
'A'
|
InitiatorID(8 byte)
|
自定义
|
RootKeyIndex(1 byte)
|
自定义
|
SessionKey(1 byte)
|
b0为1
|
EncAlg(2 byte)
|
b0为1,b6~b15为0
|
MDInfo(5 byte)
|
自定义
|
Reserved(6 byte)
|
0
|
CheckSum(2 byte)
|
对消息头和消息体数据进行CheckSum校验
|
注意:在没有预置密钥的情况下RootKeyIndex的值应该为0。
|
6.9.3 数据交换测试
测试项目:数据交换测试
|
测试目的:
验证发起方DUT在数据交易阶段的数据格式、逻辑操作和响应时间是否符合要求
|
预置条件:按照图5进行连接。
|
测试步骤:
测试子项1:
|
GB/T 33740—2017
GB/T 33740—2017
GB/T 33740—2017
GB/T 33740—2017
预期结果:
1.执行测试子项1~6,DUT 应按照测试流程进行处理,不出现测试
Fail的情况。
2.APDATA REQ(tl) 的数据格式符合下表要求:
Rfu(4 bit)
|
0
|
FormatType(4 bit)
|
8
|
Status(8 bit)
|
0x00或者0xD0~0xFF
|
MsgCode(8 bit)
|
19
|
MsgLen(16 bit)
|
24
|
EncPayLoad
|
见附录C中APDATA REQ(t1)的定义
|
CheckSum(2 byte)
|
对消息头和消息体数据进行CheckSum校验。
|
3.APDATA REQ(t2)2 的数据式符合下表要求:
|
GB/T 33740—2017
Rfu(4 bit)
|
0
|
FormatType(4 bit)
|
8
|
Status(8 bit)
|
0x00或者0xD0~0xFF
|
MsgCode(8 bit)
|
19
|
MsgLen(16 bit)
|
248
|
EncPayLoad
|
见附录C中APDATA REQ(t2)的定义
|
CheckSum(2 byte)
|
对消息头和消息体数据进行CheckSum校验。
|
6.9.4 链路维持测试
测试项目:链路维持测试
|
测试目的:
验证发起方DUT
在链路维持阶段的数据格式、逻辑操作和响应时间是否符合要求。
|
预置条件:按照图5进行连接。
|
测试步骤:
测试子项1:
子项目的:测试 DUT
在链路维持阶段的消息是否正确,在收到无效的维持连接请求后的处理是
否正确。
子项步骤:
1.DUT 发送 INQUIRYoo;
2.iTester在 8 ms 内响应 ATI(t)oo;
3.iTester在 8 ms 内接收 DUT 的请求 CONNECT REQ;
4.iTester在8 ms 内响应 CONNECT RSP(t)oo;
5.DUT 在 MC 通道持续发送CHECK1 REQ 或者CHECK2 REQ,iTester 检查 MC
通道消
息的数据格式;
6.iTester 在100 ms 内接收 DUT 发送的LINKCTL REQ, 并检查 LINKCTL REQ
的数据格式;
7.iTester 在接收到 LINKCTL REQ 后 8 ms 内响应 LINKCTL RSP(e)oo;
8.iTester在100 ms 内接收来自 DUT 的命令,若未收到任何命令,或者收到
INQUIRY 或
CLOSE REQ 命令,则测试结束,否则测试 Fail。
测试流程1
INQUIRY
ATI(t)oo |
CONNECT REQ
CONNECT RSP(t)oo |
CHECK1 REQ or CHECK2 REQ
LINKCTL REQ
LINKCTL RSP(e)ao
INQUIRY or Mute or CLOSE
|
|
GB/T 33740—2017
预期结果:
1. 执行测试子项1~2,DUT 应按照测试流程进行处理,不出现测试
Fail的情况。
2.LINKCTL REQ 的数据格式符合下表要求:
|
|
字段
|
值
|
|
|
Rfu(4 bit)
|
0
|
|
FormatType(4 bit)
|
8
|
|
Status(8 bit)
|
0x00或者0xD0~0xFF
|
|
MsgCode(8 bit)
|
22
|
|
MsgLen(16 bit)
|
2
|
|
RandData(1 byte)
|
随机数
|
|
Reserved(1 byte)
|
0
|
|
CheckSum(2 byte)
|
对消息头和消息体数据进行CheckSum校验。
|
GB/T 33740—2017
|
字段
|
值
|
|
|
MsgCode(4 bit)
|
2
|
|
|
MsgLen(4 bit)
|
2
|
|
|
CDC(2 Byte)
|
取当前响应方生成的随机数IDs的前2字节。
|
|
CHECK2 REQoo:
|
|
字段
|
值
|
|
|
MsgCode(4 bit)
|
3
|
|
|
MsgLen(4 bit)
|
2
|
|
|
TRI(2 Byte)
|
取当前响应方生成的随机数IDs的前2字节。
|
|
6.9.5 关闭连接测试
测试项目:关闭连接测试
|
测试目的:
验证发起方 DUT
在关闭连接阶段的数据格式、逻辑操作和响应时间是否符合要求。
|
预置条件:按照图5进行连接。
|
测试步骤:
测试子项1:
子项目的:测试 DUT 在接收阶段的消息命令是否正确。
子项步骤:
1.DUT 发 送 INQUIRYo;
2.iTester在 8 ms 内响应有效的 ATI(t)oo;
3.DUT 发 送 CONNECT REQ;
4.iTester在8 ms 内响应 CONNECT RSP(t)oo;
5.DUT 在MC 通道持续发送CHECK1 REQ 或者CHECK2 REQ, 在RF 通道发送CLOSE
REQ;
6.iTester检查 CLOSE REQ 数据格式,进行正确的回应;
7.iTester接收 DUT 的命令,若未收到任何命令,或者收到 INQUIRY
命令,则测试结束,否则
测试 Fail。
测试流程1
INQUIRYo
ATI(t)a。 |
CONNECT REQ
CONNECT RSP(t)o |
CHECK1 REQ or CHECK2 REQo
|
CLOSE REQ
Mute or CLOSE RSP(t) |
INQUIRY or Mute
|
|
style="width:12.37332in" />
GB/T 33740—2017
预期结果:
1.执行测试子项1,DUT应按照测试流程进行处理,不出现测试Fail的情况。
2.CLOSE REQ的数据格式符合下表要求:
|
|
字段
|
值
|
|
|
Rfu(4 bit)
|
0
|
|
|
FormatType(4 bit)
|
8
|
|
|
Status(8 bit)
|
0x00或者0xD0~0xFF
|
|
|
MsgCode(8 bit)
|
26
|
|
|
MsgLen(16 bit)
|
4
|
|
|
NeedResp(1 byte)
|
0或1
|
|
|
Reserved(3 byte)
|
0
|
|
|
CheckSum(2 byte)
|
对消息头和消息体数据进行CheckSum校验。
|
|
6.9.6 异常处理测试
测试项目:异常处理测试
|
测试目的:
验证发起方DUT异常处理机制的逻辑操作和响应时间是否符合要求。
|
预置条件:按照图5进行连接。
|
测试步骤:
测试子项1:
子项目的:测试DUT在交易阶段收到状态异常(0x01)的维持连接响应消息后,处理是否正确。
子项步骤:
1 .DUT发送INQUIRYoo;
2.iTester在8 ms内响应有效的ATI(t)oo;
3 . D U T 发 送 C O N N E C T R E Q ;
4.iTester在8ms内响应CONNECT RSP(t)oo;
5 . DUT在MC通道持续发送CHECK1 REQ)或者CHECK2 REQ;
6. iTester在100 ms内接收DUT的LINKCTL REQoo;
7.iTester在8ms内响应LINKCTL RSP(t)。,其Status字段置为0x01;
8.iTester在100 ms内等待DUT的命令,若收到CLOSE
REQ命令,则测试结束,否则测试
Fail。
|
GB/T 33740—2017
|
DUT 发起方测试仪iTester
|
|
INQUIRY
ATI(t)a |
CONNECT REQ
CONNECT RSP(t)ao |
CHECK1 REQor CHECK2 REQ
LINKCTL REQ
LINKCTL RSP(t)oo |
CLOSE REQ
|
子项预期结果:见"预期结果"。
测试子项2:
子项目的:测试DUT
在交易阶段收到状态异常(0x02)的维持连接响应消息后,处理是否正确。
子项步骤:
1.DUT 发送 INQUIRY₀ 1;
2.iTester在 8 ms 内响应有效的 ATI(t)oi;
3.DUT 发送 CONNECT REQ;
4.iTester在8 ms 内响应 CONNECT RSP(t)oi;
5.DUT 在 MC 通道持续发送 CHECK1 REQ 或者CHECK2 REQo;
6.iTester在100 ms 内接收 DUT 的 LINKCTL REQ;
7.iTester在 8 ms 内响应 LINKCTL RSP(t)o, 其 Status 字段置为0x02;
8.iTester 在100 ms 内等待DUT 的命令,若收到CLOSE REQ
命令,则测试结束,否则测试 Fail。
测试流程2
INQUIRYo
ATI(t)o |
CONNECT REQ
CONNECT RSP(t)ai |
CHECK1 REQor CHECK2 REQ
LINKCTL REQ
LINKCTL RSP(t)oi |
CLOSE REQ
|
子项预期结果:见"预期结果"。
测试子项3:
子项目的:测试 DUT
在交易阶段收到状态异常(0x82)的维持连接响应消息后,处理是否正确。
子项步骤:
1.DUT 发送INQUIRYo₂ ;
2.iTester在8 ms 内响应有效的 ATI(t)o₂ ;
3.DUT 发送 CONNECT REQ;
|
GB/T 33740—2017
GB/T 33740—2017
GB/T 33740—2017
|
DUT 发起方测试仪iTester
|
|
INQUIRYos
ATI(t)os |
CONNECT REQ
CONNECT RSP(t) |
CHECK1 REQsor CHECK2 REQ
|
APDATA REQ
_
APDATA RSP(t)os |
CLOSE REQ
|
子项预期结果:见"预期结果"。
测试子项7:
子项目的:测试 DUT
在交易阶段收到状态异常(0x01)的长时间等待消息后,处理是否正确。
子项步骤:
1.DUT 发送 INQUIRYo₆ ;
2.iTester在8 ms 内响应有效的 ATI(t)o₆ ;
3.DUT 发 送 CONNECT REQo₆ ;
4.iTester在8 ms 内响应 CONNECT RSP(t)os;
5.DUT 在 MC 通道持续发送CHECK1 REQ 或者CHECK2 REQo₆ ;
6.DUT 发 送 APDATA REQ;
7.iTester在 8 ms 内响应 LTW(t) ,其 Status字段置为0x01;
8.iTester 在100 ms 内接收DUT 的命令,若收到CLOSE REQ
命令,则测试结束,否则测试 Fail。
测试流程7
INQUIRYo₆
ATI(t)os |
CONNECT REQ
CONNECT RSP(t) |
CHECK1 REQor CHECK2 REQ
|
APDATA REQ
_
LTW(t)os |
CLOSE REQ
|
|
GB/T 33740—2017
GB/T 33740—2017
预期结果:
执行测试子项1~10,DUT 应按照测试流程进行处理,不出现测试
Fail的情况。
|
6.9.7 超时时间测试
测试项目:超时时间测试
|
测试目的:
验证发起方DUT在激活阶段、连接阶段、链路维持阶段、数据交易阶段的超时时间是否符合
要 求 。
|
预置条件:按照图5进行连接。
|
测试步骤:
测试子项1:
子项目的:测试DUT在激活阶段的超时时间。
子项步骤:
|
GB/T 33740—2017
GB/T 33740—2017
GB/T 33740—2017
GB/T 33740—2017
GB/T 33740—2017
style="width:12.37361in;height:11.22708in" />
6.9.8 加密算法验证
测试项目:加密算法验证
|
测试目的:
验证发起方DUT支持的加密算法是否符合要求。
|
预置条件:按照图5进行连接。
|
测试步骤:
1 .DUT发送INQUIRYoo;
2.iTester再响应ATI(t)oo;
3.iTester在8 ms内接收CONNECT REQoo;
4.iTester在收到CONNECT
REQ后根据EncAlg的值查找下表,执行对应的测试子项,若
EncAlg的值不在下表中,则直接测试Fail。
|
GB/T 33740—2017
0001
|
子项1
|
0002
|
子项2
|
0003
|
子项1、2
|
0004
|
子项3
|
0005
|
子项1、3
|
0006
|
子项2、3
|
0007
|
子项1、2、3
|
0008
|
子项4
|
0009
|
子项1、4
|
000A
|
子项2、4
|
000B
|
子项1、2、4
|
000C
|
子项3、4
|
000D
|
子项1、3、4
|
000E
|
子项2、3、4
|
000F
|
子项1、2、3、4
|
0010
|
子项5
|
0011
|
子项1、5
|
0012
|
子项2、5
|
0013
|
子项1、2、5
|
0014
|
子项3、5
|
0015
|
子项1、3、5
|
0016
|
子项2、3、5
|
0017
|
子项1、2、3、5
|
0018
|
子项4、5
|
0019
|
子项1、4、5
|
001A
|
子项2、4、5
|
001B
|
子项1、2、4、5
|
001C
|
子项3、4、5
|
001D
|
子项1、3、4、5
|
001E
|
子项2、3、4、5
|
001F
|
子项1、2、3、4、5
|
0020
|
子项6
|
0021
|
子项1、6
|
0022
|
子项2、6
|
0023
|
子项1、2、6
|
GB/T 33740—2017
0024
|
子项3、6
|
0025
|
子项1、3、6
|
0026
|
子项2、3、6
|
0027
|
子项1、2、3、6
|
0028
|
子项4、6
|
0029
|
子项1、4、6
|
002A
|
子项2、4、6
|
002B
|
子项1、2、4、6
|
002C
|
子项3、4、6
|
002D
|
子项1、3、4、6
|
002E
|
子项2、3、4、6
|
002F
|
子项1、2、3、4、6
|
0030
|
子项5、6
|
0031
|
子项1、5、6
|
0032
|
子项2、5、6
|
0033
|
子项1、2、5、6
|
0034
|
子项3、5、6
|
0035
|
子项1、3、5、6
|
0036
|
子项2、3、5、6
|
0037
|
子项1、2、3、5、6
|
0038
|
子项4、5、6
|
0039
|
子项1、4、5、6
|
003A
|
子项2、4、5、6
|
003B
|
子项1、2、4、5、6
|
003C
|
子项3、4、5、6
|
003D
|
子项1、3、4、5、6
|
003E
|
子项2、3、4、5、6
|
003F
|
子项1、2、3、4、5、6
|
测 试 子 项 1 :
子 项 目 的 : 测 试 D U T 的 3 D E S - E C B 算 法 。
子 项 步 骤 :
1 . 在 D U T 的 工 作 区 域 内 放 置 发 起 方 测 试 仪 i T e s t e r
;
2 . D U T 发 送 I N Q U I R Y o o ;
3 . iTester响应ATI(t)oo;
4 . i T e s t e r 在 8 m s 内 接 收 C O N N E C T R E Q ;
|
5.DUT 在 MC 通道持续发送CHECK1 REQ 或者 CHECK2 REQ;
GB/T 33740—2017
GB/T 33740—2017
GB/T 33740—2017
|
|
INQUIRY
ATI(t)o₄ |
|
|
CONNECT REQ
|
CONNECT RSP(t)o₄ |
|
CHECK1 REQor CHECK2 REQ
APDATA REQ
|
|
子项预期结果:见"预期结果"。
测试子项6:
子项目的:测试 DUT 的 SM4-CBC 算法。
子项步骤:
1. 在 DUT 的工作区域内放置发起方测试仪 iTester;
2.DUT 发送 INQUIRYos;
3.iTester 响应 ATI(t)os;
4.iTester在8 ms 内接收CONNECT REQ;
5.iTester在 8 ms 内响应 CONNECT RSP(t)os,EncAlg 的值为0x0020;
6.DUT 在 MC 通道持续发送CHECK1 REQ 或者 CHECK2 REQ₅ ;
7.DUT 发送 APDATA REQ, 其 EncPayload 字段的明文数据已知;
8.iTester接收 ADATA REQ, 进行加密算法验证。
测试流程6
|
DUT 发起方测试仪iTester
|
INQUIRYo
ATI(t)o5 |
CONNECT REQ
CONNECT RSP(t)os |
CHECK1 REQor CHECK2 REQ
|
APDATA REQ
|
GB/T 33740—2017
6.9.9 频点范围测试
测试项目:频点范围测试
|
测试目的:
验证发起方DUT的频点范围是否符合要求。
|
预置条件:按照图5进行连接。
|
测试步骤:
测试子项1:
子项目的:测试DUT的工作频点是否正确。
子项步骤:
1 .DUT发送INQUIRYoo;
2.iTester设置IDs字段选择射频工作频点,然后响应ATI(t)oo;
3 . iTester在8ms内接收CONNECT
REQ,如果在设置的工作频点上未收到CONNECT
REQ,则测试Fail;
4. iTester在8ms内响应CONNECT RSP(t)oo;
5.iTester在100 ms内接收DUT的其他命令;
6.重复执行第2步~第5步,直到遍历完成所有64个工作频点(2401MHz~2464
MHz)。
测试流程1
|
|
DUT 发起方测试仪iTester
|
INQUIRY
ATI(t)ao |
CONNECT REQo
— CONNECT RSP(t)o。
LINKCTL REQor APDATA REQ
.. … ...…
|
子项预期结果:见"预期结果"。
测试子项2:
子项目的:验证DUT的冲突响应频点是否正确。
子项步骤:
如果DUT在维持连接阶段通过磁通道发送的消息为CHECK1
REQ,则进行该项测试,否则不
进行该项测试。
|
GB/T 33740—2017
预期结果:
执行测试子项1和2,DUT 应按照测试流程进行处理,不出现测试 Fail
的情况。
|
GB/T 33740—2017
附 录 A
(规范性附录)
标准感应线圈
标准感应线圈为在 PCB
上制作而成的印制线圈,在第一层上绕制9匝线圈后,通过过孔连接至下
一层再绕制9匝线圈,以此类推,共完成6层线圈的绕制,6层线圈的绕制方向保持一致(同为顺时针方
向或同为逆时针方向),共54匝线圈。线圈的线宽均为0.15 mm, 线间距均为0.15
mm, 其单层结构如
图 A.1 所示。标准感应线圈其他主要参数为:
— 介质材料:FR4;
— 介质厚度:0.32 mm;
— 布线层数:6;
导 体 材 料 : 铜 ;
导体厚度:35 μm ;
— 成品厚度:1.6(1±10%)mm;
——直流电阻:12.5 Ω(1±15%)Ω。
style="width:3.73997in;height:2.29988in" />
图 A.1 标准感应线圈单层结构示意图
style="width:1.14664in;height:0.63998in" />style="width:3.49343in;height:0.64658in" />
GB/T 33740—2017
附 录 B
(资料性附录)
磁通道感应电压与场强的推导
style="width:6.47332in;height:3.11344in" />
图 B. 1 标准磁通道磁场信号调制波形
如图 B. 1
所示,标准的磁通道磁场信号调制波形是等斜率(绝对值)的,所以标准感应线圈处于该磁
场中时,感应到的电压峰值应为:
style="width:3.52002in;height:0.61336in" />
因为在标准感应线圈范围内的磁场强度呈较均匀的分布,所以面积 S 范 围 内
,B 恒定,所以上式可
以转换为:
style="width:6.40677in;height:0.62656in" />
由 图 B. 1 可 知 ,
style="width:2.47328in;height:0.6534in" />
所 以 ,
style="width:1.44007in;height:0.66682in" />
式 中
上述推导中:
— Hp 为磁场强度峰值;
——Vp 为感应电压峰值;
— Vpp为感应电压峰峰值;
— T 。为符号周期(250μs);
——N 为标准感应线圈匝数;
— S 为标准感应线圈等效面积;
μ为真空磁导率(4π*10 - 1)。
GB/T 33740—2017
附 录 C
(规范性附录)
测试命令
C.1 概述
本附录定义了协议测试中使用的有效测试命令和无效测试命令,其中有效测试命令格式和内容均
符合GB/T 33736—20179.3
的规定,无效测试命令的格式与有效测试命令相同,但其部分字段内容的
值与有效测试命令不同。
C.2 激活请求
有效激活命令 INQUIRY(t) 定义如下表:
MsgCode(4 bit)
|
0
|
MsgLen(4 bit)
|
15
|
Rfu(4 bit)
|
0
|
InitiatorVersion(4 bit))
|
3
|
IDm(14 byte)
|
随机数
|
无效激活命令INQUIRY(e) 的 MsgCode 值与上表不同,或者 MsgLen 或
InitiatorVersion 值与上
表不同,其余内容与上表一致。
C.3 激 活 响 应
有效的激活响应 ATI(t) 定义如下表:
Rfu(4 bit)
|
0
|
FormatType(4 bit)
|
8
|
Status(1 Byte)
|
0
|
MsgCode(1 Byte)
|
16
|
MsgLen(2 Byte)
|
24
|
IDs(5 byte)
|
随机数
|
TargetID(8 Byte)
|
响应方标识(自定义)
|
AccessVersion(1 byte)
|
0x03
|
Mac(4 Byte)
|
响应方使用KO作为密钥对
(IDs | |TargetID | |AccessVersion)
进行MAC计算。16字节K0使用SKG0中同样
的扩展方式由14字节IDm扩展生成。
MAC算法见GB/T 33736 — 2017附录B.5。
|
Reserved(6 Byte)
|
0
|
CheckSum(2 Byte)
|
对消息头和消息体数据进行CheckSum校验。
|
GB/T 33740—2017
无效的激活命令 ATI(e) 的 Mac 值与正确值不同,其余内容与上表一致。
C.4 连接请求
有效的连接请求 CONNECT REQ(t) 的定义如下:
Rfu(4 bit)
|
0
|
FormatType(4 bit)
|
8
|
Status(8 bit)
|
0
|
MsgCode(8 bit)
|
17
|
MsgLen(16 bit)
|
24
|
InitiatorType(1 byte)
|
'A'
|
InitiatorID(8 byte)
|
随机数
|
RootKeylndex(1 byte)
|
0x00
|
SessionKey(1 byte)
|
0x01
|
EncAlg(2 byte)
|
0x0100
|
MDInfo(5 byte)
|
随机数
|
Reserved(6 byte)
|
0
|
CheckSum(2 byte)
|
对消息头和消息体数据进行CheckSum校验。
|
无效的连接请求 CONNECT REQ(e) 的 CheckSum
值与正确值不同,其余内容与上表一致。
C.5 连接响应
有效的连接响应 CONNECT RSP(t) 的定义如下:
Rfu(4 bit)
|
0
|
FormatType(4 bit)
|
8
|
Status(8 bit)
|
0x00
|
MsgCode(8 bit)
|
18
|
MsgLen(16 bit)
|
24
|
Result(1 Byte)
|
0x00
|
RootKeyIndex(1 Byte)
|
0x00
|
SessionKey(1 Byte)
|
0x01
|
EncAlg(2 Byte)
|
0x0100
|
SDInfo(5 Byte)
|
自定义
|
SDRand(8 Byte)
|
随机数
|
Reseved(6 Byte)
|
0
|
CheckSum(2 Byte)
|
对消息头和消息体数据进行CheckSum校验。
|
GB/T 33740—2017
C.6 数据交换请求
数据交换请求包括 APDATA REQ(tl),APDATA REQ(t2),APDATA REQ(t3),APDATA
REQ(t4) 和 APDATA REQ(e)
有效的数据交换请求 APDATA REQ(t1) 定义如下表所示:
Rfu(4 bit)
|
0
|
FormatType(4 bit)
|
8
|
Status(8 bit)
|
0
|
MsgCode(8 bit)
|
19
|
MsgLen(16 bit)
|
24
|
EncPayLoad
|
对明文数据(0x990x990x000x00+0x0D+13Byte随
机数)加密后得到的密文数据,加密算法由连接阶段双
方商定。
|
CheckSum(2 byte)
|
对消息头和消息体数据进行CheckSum校验。
|
错误的数据交换请求 APDATA REQ(e) 的 CheckSum
值与正确值不同,其余内容与上表一致。
APDATA REQ(t2) 定义如下表所示:
Rfu(4 bit)
|
0
|
FormatType(4 bit)
|
8
|
Status(8 bit)
|
0
|
MsgCode(8 bit)
|
19
|
MsgLen(16 bit)
|
248
|
EncPayLoad
|
对明文数据(0x990x990x000x00+0xEE+238Byte随
机数)加密后得到的密文数据,加密算法由连接阶段双
方商定。
|
CheckSum(2 byte)
|
对消息头和消息体数据进行CheckSum校验。
|
APDATA REQ(t3)
为消息长度超出本系列标准规定的数据交换请求指令,定义如下表所示:
Rfu(4 bit)
|
0
|
FormatType(4 bit)
|
8
|
Status(8 bit)
|
0
|
MsgCode(8 bit)
|
19
|
MsgLen(16 bit)
|
296
|
EncPayLoad
|
对明文数据(x990x990x000x00 +0x010x22 +
290Byte随机数)加密后得到的密文数据,加密算法由连
接阶段双方商定。
|
CheckSum(2 byte)
|
对消息头和消息体数据进行CheckSum校验。
|
APDATA REQ(t4) 为有效数据请求指令,其定义与 APDATA REQ(t1)
APDATA REQ(t4) 指令的处理时间超过500 ms。
GB/T 33740—2017
相同,但响应方DUT 对
C.7 数据交换响应
有效的数据响应 APDATA RSP(t) 与当前数据交换请求命令 APDATA REQ 对应。
若当前数据交换请求命令为 APDATA REQ(t1), 则 APDATA RSP(t) 定义如下:
错误的 APDATA RSP(e),CheckSum 值与正确值不相同。
Rfu(4 bit)
|
0
|
FormatType(4 bit)
|
8
|
Status(8 bit)
|
0
|
MsgCode(8 bit)
|
20
|
MsgLen(16 bit)
|
24
|
EncPayLoad(24 Byte)
|
对当前APDATA REQ(t1)的数据内容进行解密得到明
文数据,将明文数据‘0x990x990x000x00'去掉,并在其
尾部加上‘0x900x00',然后将处理后的明文数据再
加 密 。
|
CheckSum(2 Byte)
|
对消息头和消息体数据进行CheckSum校验。
|
若当前数据交换请求命令为 APDATA REQ(t2), 则 APDATA RSP(t) 定义如下:
错误的 APDATA RSP(e),CheckSum 值与正确值不相同。
Rfu(4 bit)
|
0
|
FormatType(4 bit)
|
8
|
Status(8 bit)
|
0
|
MsgCode(8 bit)
|
20
|
MsgLen(16 bit)
|
248
|
EncPayLoad(248 Byte)
|
对当前APDATA REQ(t2)的数据内容进行解密得到明
文数据,将明文数据‘99990000'去掉,并在其尾部加上
9000',然后将处理后的明文数据再加密。
|
CheckSum(2 Byte)
|
对消息头和消息体数据进行CheckSum校验。
|
C.8 长时等待命令
有效的长时等待命令 LTW(t) 定义如下:
GB/T 33740—2017
Rfu(4 bit)
|
0
|
FormatType(4 bit)
|
8
|
Status(8 bit)
|
0
|
MsgCode(8 bit)
|
25
|
MsgLen(16 bit)
|
2
|
RandData(1Byte)
|
随机数
|
Reserved(1 Byte)
|
0
|
CheckSum(2 Byte)
|
对消息头和消息体数据进行CheckSum校验。
|
无效的长时等待命令 LTW(e) 的 CheckSum
值与正确值不同,其余内容与上表一致。
C.9 维持连接请求
有效的维持连接请求 LINKCTL REQ(t) 定义如下:
Rfu(4 bit)
|
0
|
FormatType(4 bit)
|
8
|
Status(8 bit)
|
0
|
MsgCode(8 bit)
|
22
|
MsgLen(16 bit)
|
2
|
RandData(1 byte)
|
随机数
|
Reserved(1 byte)
|
0
|
CheckSum(2 byte)
|
对消息头和消息体数据进行CheckSum校验。
|
无效的维持连接请求 LINKCTL REQ(e)
C.10 维持连接响应
有效的维持连接请求 LINKCTL RSP(t)
的 CheckSum 值与正确值不同,其余内容与上表一致。
定义如下:
Rfu(4 bit)
|
0
|
FormatType(4 bit)
|
8
|
Status(8 bit)
|
0
|
MsgCode(8 bit)
|
23
|
MsgLen(16 bit)
|
2
|
RandData(1 byte)
|
随机
|
Reserved(1 byte)
|
0
|
CheckSum(2 byte)
|
对消息头和消息体数据进行CheckSum校验。
|
无效的维持连接请求 LINKCTL RSP(e)
C.11 冲突检测命令
有效的冲突检测命令 CHECK1 REQ(t)
GB/T 33740—2017
的 CheckSum 值与正确值不同,其余内容与上表一致。
定义如下:
MsgCode(4 bit)
|
2
|
MsgLen(4 bit)
|
2
|
CDC(2 byte)
|
取当前响应方生成的随机数IDs的前2字节。
|
无效的冲突检测命令 CHECK1 REQ(e) 的 CDC
值与正确值不同,其余内容与上表一致。
C.12 冲突响应消息
冲突响应消息 CHECK RSP(t1) 定义如下:
Rfu(4 bit)
|
0
|
FormatType(4 bit)
|
8
|
Status(8 bit)
|
0 or 1 |
MsgCode(8 bit)
|
24
|
MsgLen(16 bit)
|
16
|
RandData(1 byte)
|
随机
|
TargetID(8 byte)
|
响应方标识
|
Reserved(7 byte)
|
0
|
CheckSum(2 byte)
|
对消息头和消息体数据进行CheckSum校验。
|
冲突响应消息 CHECK RSP(t2)
一致。
的 TargetID 值与当前接入的卡片 ID 不同,其余内容与上表
C.13 连接确认
有效的连接确认消息 CHECK2 REQ(t) 定义如下:
MsgCode(4 bit)
|
3
|
MsgLen(4 bit)
|
2
|
TRI(2 Byte)
|
取当前响应方生成的随机数IDs的前2字节。
|
无效的连接确认消息CHECK2 REQ(e) 的 CDC
值与正确值不同,其余内容与上表一致。
GB/T 33740—2017
C.14 关闭连接请求
有效的关闭连接请求 CLOSE REQ(t1) 定义如下:
Rfu(4 bit)
|
0
|
FormatType(4 bit)
|
8
|
Status(8 bit)
|
0
|
MsgCode(8 bit)
|
26
|
MsgLen(16 bit)
|
4
|
NeedResp(1 byte)
|
1
|
Reserved(3 byte)
|
0
|
CheckSum(2 byte)
|
对消息头和消息体数据进行CheckSum校验。
|
有效的关闭连接请求 CLOSE REQ(t2)
无效的关闭连接请求 CLOSE REQ(e)
的 NeedResp
的 CheckSum
值为0,其余内容与上表一致。
值与正确值不同,其余内容与上表一致。
C.15 关闭连接响应
有效的关闭连接响应 CLOSE RSP(t) 定义如下:
Rfu(4 bit)
|
0
|
FormatType(4 bit)
|
8
|
Status(8 bit)
|
0
|
MsgCode(8 bit)
|
27
|
MsgLen(16 bit)
|
4
|
CloseResult(1 byte)
|
0
|
Reserved(3 byte)
|
0
|
CheckSum(2 byte)
|
对消息头和消息体数据进行CheckSum校验。
|
延伸阅读
更多内容 可以 GB-T 33740-2017 手机支付 基于2.45GHz RCC 限域通信 技术的非接触射频接口测试方法. 进一步学习
联系我们
DB62-T 4669-2023 陇东苜蓿 甘肃省.pdf